Motivation

I toyed over the weekend with some code to enable expression templates in eamxx. Then I thought that it was maybe easier to work directly with views, so I moved to ekat. The framework should be lightweight in terms of performance, but I haven't tested it yet. I tested an earlier version in eamxx, which had more runtime overhead, and it was ~50% slower than a big manual loop. I am hoping that this ekat version (fully templated) will be faster and closer to parity with a manual loop.

The framework allows to create expressions from views and scalar, and then evaluate them (stuffing the result in a view). Something of the form

// x, y, and z are all views of the same shape
auto expression = x*exp(-y) - 2*sin(y);
evaluate(expression, z);

The first line creates an "expression", which is a compile-time evaluation tree. The second line performs a flat || for to evaluate it (uses RangePolicy in 1d, and MDRangePolicy otherwise).

So far, it only supports 1d,2d,and 3d views, and always evaluates the result as a double. If needed, I think we can easily expand to a generic type, at the cost of increasing the template signature of each class.

Testing

Added a unit test for 1d,2d,3d. Performs binary ops, simple math fcns, and ternary-operator-like evaluations.

Additional Information

I went back and forth between a couple of impl choices, namely whether eval should accept indices (like eval(int i, int j)) or accept no inputs, but require to set the evaluation data in the expression at each iteration. I think the former is prob faster, so I went with that, at the cost of increasing the number of methods to implement.

A few things I'd like to try:

• Add support for ViewBroadcast: would allow do multiply a 2d view with a 3d one, along the proper indices. This may require additional info on what each index represent though, which adds complexity (but maybe not too much).
• Add support for 1d reductions: e.g., do something like z = x + reduction(y,1), which reduces y along 2nd dim, then adds to x.
• Linked to the above: if inner evaluations need to do a bit of work to compute each entry of the output (like reduction(y,1)), it would help to have evaluate switch betwen range and team policies, based on what expresison needs. This would require the expression to expose some "policy data", which could be something like "range is fine", or "needs team". This can prob be done at compile time, as each expression knows at compile time what kind of work it does, and the binary ops that compose expressions can ping inner expressions for this info.
• Remove the hard-coded Real as the return type of the eval methods. This may require that all expressions be based on their return type, and the return type of compositions is then chosen based on promotion rules.